1. Field of the Invention
The present invention relates to computer systems for servicing data and application requests generated by a number of users on client systems connected through a network. More particularly, the invention relates to servicing requests in a service oriented application. Still more particularly, the invention relates to systems for providing data at varying levels of detail selectable by the requesting client.
2. Description of Related Art
Networked computer systems have existed for many years. Such systems allow data to be stored at a central location and supplied to other locations as required by a business or enterprise. For example, the records of a bank may be maintained on centralized computers with tightly controlled facilities and applications. A bank teller accesses the data through a client system or terminal that queries the central computers when data is needed.
Early server or mainframe based systems used “dumb” terminals that were able to access data only according to a format or program stored on the server. The interaction between the client and server was strictly defined by the server. This limited the flexibility of the systems because any requirement to access data in a new or different way required the server software to be changed.
A next generation of networked systems employed “client-server” architectures that provide a “smart” client such as a personal computer or workstation, connected by a network to a server. The “smart” client could run software on its own and modify or reformat data accessed from a server before that data was presented to the client user. These systems provided more flexibility but were still subject to strict limits on which clients could access a computer and what types of data could be accessed. A major change to client requirements typically required a coordinated change to both server and client software systems.
Recent developments have led to the creation of a network architecture known as a “Service Oriented Architecture” or SOA. SOA seeks to make client applications more independent of server applications. In this architecture, the server provides one or more “Services.” Each service provides defined functions through well defined application programming interfaces or APIs. Clients systems can then assemble the outputs of many service objects to create unique client applications that can be changed or modified by changing the services accessed. In addition, the services can be changed or upgraded independently of the clients as long as they continue to support the defined APIs.
Increased independence of the client applications from the service objects allows the client to be flexibly reconfigured. Reconfiguration can add access to different services or can replace one service with another that provides superior information. Similarly, the service or server system can focus on providing a high quality and efficient response to a well defined query. It can incorporate new technologies and approaches without fear of harming the client application.
Unfortunately, the desire to have a service object be generally accessible by a multitude of clients requires that the service object APIs be fairly coarse grained in the data returned. By coarse grained it is meant that the data returned is not filtered or limited only to the data necessary for the client application but instead is more broadly defined as responsive to a service request. For example, a service object that provides information about customer accounts will provide all customer account information even though the client does not require all of the information. In this example, a bank teller may need to access a customer's telephone number. The bank teller client system will request this information from the account service object and receive back all of the information maintained on the customer account. This leads to inefficient use of network bandwidth and computing resources.
One solution is to define more detailed service object interfaces or APIs. In the example, an API could be defined that returns only the customer telephone number. The problem with this approach is that increasing the number of service object interfaces decreases the independence of the client and increases the work required to support the server hosting the service object. As the number of detailed APIs increase they approach the complexity and binding of client/server computer systems.
Thus, a technical problem exists in providing a generalized server system with a service interface that is accessible to a large number of clients through a generalized coarse grained API yet is able to provide fine grained or focused data to the clients.